Intra-vehicle message traffic may be encrypted. For example, a vehicle may have a number of electronic modules interconnected by a data bus, and the modules may communicate with one another over the bus to carry out vehicle functions. If a malicious attacker (e.g., a hacker) is able to gain access to the bus, the attacker may be able to manipulate or otherwise control some vehicle functions—e.g., to the detriment of an authorized user. Therefore, one conventional practice is to encrypt the message traffic sent over the bus (between the modules). Thus, if the attacker acquires unauthorized access, the attacker will only discover encrypted messages—making it less likely that the attacker can manipulate or control the vehicle.
During design and development, such vehicle data bus systems need to be tested to validate and verify that the system is operating properly—e.g., before the vehicle is sold to a customer (or authorized user). Vehicle manufacturers may out-source subsystem development to supplier(s). For example, the manufacturer may request a supplier to provide the bus and module interface (e.g., where the interfaces allow the modules to communicate with one another). During supplier development, the supplier often needs to test and validate the data bus system. However, the manufacturer may desire to not provide certain security data to the supplier—e.g., the manufacturer may desire to not provide the supplier with an encryption key to decrypt the internal message traffic. Thus, there is needed a mechanism or tool which can be provided to the supplier by which the supplier can validate the operation of the vehicle data bus system without providing the supplier the certain security data.